Traditionally, text is entered either using a hardware keyboard (e.g., 12 phone keys or QWERTY keyboard) or a software keyboard (e.g., keys are graphical buttons displayed on a touchscreen display). A major problem with this approach is that the small key sizes on handheld devices make it relatively difficult to type. Often, the keyboard is divided into several parts (letters vs. numbers vs. special characters). This allows the user to switch between parts and only one part is displayed at a time on the screen. This allows for larger buttons per part, but switching causes overhead for the user. Also, as the screen size of mobile devices decreases, users tend to make more mistakes in touching the intended character on the touch screen, thereby decreasing the overall accuracy. As a result, there is a point at which typing on a smaller screen provides no extra value in terms of speed and/or accuracy compared to the more natural user inputs like handwriting recognition.
Consequently, in the case of small screens, handwriting sometimes offers advantages over typing for personal communication. Further, handwritten notes often contain subtle personal cues through writing style and drawings that cannot be expressed by typed text. Many of today's communication devices, such as, for example, smart phones, tablet computers, etc., have touchscreen-based systems that are capable of recording handwriting that is entered on a touchscreen of the device. Several commercial applications employ handwriting for note taking and messaging. Unfortunately, these types of handwriting applications typically require either a stylus, or a surface large enough for a finger to write with sufficient precision. This poses a problem for the small screens of mobile devices.
For example, one conventional handwriting technique provides a phone-based application wherein the user writes characters in the phone's landscape mode. A user touch of the far left side of the screen (or waiting for a timeout) accepts the writing and clears the screen for more input. Unfortunately, this approach requires the user to organize her input spatially such that an “accept and clear” type action is triggered, and so that a proper amount of space surrounds each character, since characters are concatenated by including leading and trailing whitespace. In addition, the landscape orientation of this application necessitates frequent rotation of the device. Another similar application uses a two-finger swipe gesture to manually arrange predefined ink segments on the screen to form individual characters.
In an attempt to address the limited space available for writing with fingers on small screens, various automatic segmentation techniques have been implemented for use in mobile text entry scenarios. Such systems allow letters to be written on top of each other, with those letters then being separated by post-processing. For example, so-called overlapped recognition systems generally operate by evaluating the overlapping strokes to identify the intended characters, and then use that information to segment the strokes. Unfortunately, this means that these systems use a form of text or handwriting recognition that is performed jointly with stroke segmentation as a guide or aid for use in segmenting the strokes, with a resulting increase in complexity and computational overhead requirements. One approach that avoids the character segmentation problem is the use of custom unistroke alphabets where every individual stroke represents a different character. Such techniques can allow eyes-free input, but require the user to learn a new gesture set (i.e., different single strokes for each individual character) to enter text.
Another finger-input handwriting approach allows users to write overlapping characters on a touch surface through fabric. This approach generally recognizes single stroke letters (e.g., “c” or “l”) without further user action. However, in order to segment overlapping strokes for more complex characters such as (“k” “t” “f” and “x”), this approach looks for a second specific stroke. In particular, if a “<” “-” “\” or “/” gesture is encountered, this approach simply merges that stroke with the previously entered stroke to produce a character. In other words, this approach either identifies single strokes as characters, or looks for one or more special identifier strokes or gestures to indicate that consecutive strokes are to be merged. Without identifying this type of special character, this system is not capable of segmenting multiple overlapping strokes to determine what character was intended by the user.